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Abstract.  Standard  type  systems  are  not  sufficiently  expressive  when  applied  to 
low-level  memory-management  code.  Such  code  often  uses  some  form  of  strong 
update  (i.e.  assignments  that  change  the  type  of  the  affected  location)  and  needs  to 
reason  about  the  relative  position  of  objects  in  memory.  We  present  a  novel  type 
system  which,  like  alias  types  [20],  provides  a  form  of  strong  update,  but  with  the 
advantage  that  it  does  not  require  the  aliasing  pattern  to  be  statically  described.  It 
also  provides  operations  over  sequential  memory  locations  and  allows  covariant 
reference  casts.  We  then  show  how  this  new  type  system  can  be  used  to  implement 
a  type-safe  stop&copy  garbage  collector  that  can  properly  collect  cyclic  data- 
structures.  More  specifically,  we  show  how  to  write  a  two-generations  collector 
for  a  language  with  mutable  ref  cells. 


1  Introduction 

As  the  technology  of  certifying  compilation  and  proof  carrying  code  [13,  1,  6]  has 
progressed,  the  need  to  ensure  the  safety  of  the  runtime  system  has  increased.  After  all, 
if  you  go  through  the  trouble  of  writing  a  foundational  proof  of  safety  of  your  code,  you 
would  rather  not  trust  an  unverified  conservative  garbage  collector  (GC)  with  your  data. 
For  this  reason,  it  is  very  important  to  be  able  to  write  a  type-safe  GC,  but  the  state  of 
the  art  in  this  matter  is  still  completely  impractical  since  they  cannot  even  handle  cyclic 
data-structures.  This  paper’s  main  goals  are  thus: 

-  Show  that,  in  order  to  type-check  a  GC  that  can  collect  cyclic  data-structures,  the 
type  system  has  to  provide  a  form  of  strong  update  that  can  change  the  type  of  a 
location  even  if  the  set  of  aliases  to  this  location  is  completely  unknown. 

-  Present  a  type  system  that  provides  such  a  facility.  This  type  system  allows  the 
programmer  to  choose  any  mix  of  linear  or  intuitionistic  typing  of  references  and 
to  change  this  choice  over  time  to  adapt  it  to  the  current  needs. 

-  Implement  the  first  type-preserving  GC  that  properly  collects  cycles  and  the  first 
generational  GC  that  allows  the  mutator  to  use  destructive  assignment. 

*  This  research  was  sponsored  in  part  by  the  Defense  Advanced  Research  Projects  Agency  ISO 
under  the  title  “Scaling  Proof-Carrying  Code  to  Production  Compilers  and  Security  Policies,” 
ARPA  Order  No.  H559,  issued  under  Contract  No.  F30602-99-1-0519,  and  in  part  by  NSF 
Grants  CCR-9901011  and  CCR-0081590.  The  views  and  conclusions  contained  in  this  docu¬ 
ment  are  those  of  the  authors  and  should  not  be  interpreted  as  representing  the  official  policies, 
either  expressed  or  implied,  of  the  Defense  Advanced  Research  Projects  Agency  or  the  U.S. 
Government. 


Report  Documentation  Page 


Form  Approved 
OMB  No.  0704-0188 


Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 
VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  OMB  control  number. 


1.  REPORT  DATE 

2005 


2.  REPORT  TYPE 


3.  DATES  COVERED 


4.  TITLE  AND  SUBTITLE 

Typed  Regions 


5a.  CONTRACT  NUMBER 


5b.  GRANT  NUMBER 


5c.  PROGRAM  ELEMENT  NUMBER 


5d.  PROJECT  NUMBER 


5e.  TASK  NUMBER 


5f.  WORK  UNIT  NUMBER 


6.  AUTHOR(S) 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES)  8.  PERFORMING  ORGANIZATION 

Defense  Advanced  Research  Projects  Agency, 3701  North  Fairfax  report  number 

Dr,  Arlington, VA, 22203- 1714 

9.  SPONSORING/MONITORING  AGENCY  NAME(S )  AND  ADDRESS(ES )  10.  SPONSOR/MONITOR' S  ACRONYM(S) 

11.  SPONSOR/MONITOR'S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

14.  ABSTRACT 

Standard  type  systems  are  not  sufficiently  expressive  when  applied  to  low-level  memory-management  code. 
Such  code  often  uses  some  form  of  strong  update  (i.e.  assignments  that  change  the  type  of  the  affected 
location)  and  needs  to  reason  about  the  relative  position  of  objects  in  memory.  We  present  a  novel  type 
system  which,  like  alias  types  [20],  provides  a  form  of  strong  update,  but  with  the  advantage  that  it  does 
not  require  the  aliasing  pattern  to  be  statically  described.  It  also  provides  operations  over  sequential 
memory  locations  and  allows  covariant  reference  casts.We  then  show  how  this  new  type  system  can  be  used 
to  implement  a  type-safe  stop©  garbage  collector  that  can  properly  collect  cyclic  datastructures.  More 
specifically,  we  show  how  to  write  a  two-generations  collector  for  a  language  with  mutable  ref  cells. 


15.  SUBJECT  TERMS 


16.  SECURITY  CLASSIFICATION  OF: 


a.  REPORT 

unclassified 


b.  ABSTRACT 

unclassified 


c.  THIS  PAGE 

unclassified 


17.  LIMITATION  OF 

18.  NUMBER 

ABSTRACT 

OF  PAGES 

20 

19a.  NAME  OF 
RESPONSIBLE  PERSON 


Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


Traditional  type  systems  are  not  well-suited  to  reason  about  type-safety  of  low-level 
memory  management  such  as  explicit  memory  allocation,  initialization,  deallocation,  or 
reuse.  Existing  solutions  to  these  problems  either  have  a  very  limited  applicability  or 
rely  on  some  form  of  linearity  constraint.  Such  constraints  tend  to  be  inconvenient  and 
a  lot  of  work  has  gone  into  relaxing  them.  For  example,  the  alias  types  system  [20] 
is  able  to  cleanly  handle  several  of  the  points  above,  even  in  the  presence  of  arbitrary 
aliasing,  as  long  as  the  aliases  can  be  statically  tracked  by  the  type  system. 

The  reason  why  it  is  challenging  to  show  type-safety  of  low-level  memory  man¬ 
agement  is  that  for  this  kind  of  code,  the  line  between  type-safety  and  correctness  is 
blurred:  we  end  up  having  to  prove  some  non-trivial  properties  about  the  code  just  to 
show  its  type-safety.  For  example,  type-safety  of  a  generational  GC  depends  on  the  cor¬ 
rect  processing  of  the  remembered-set  (a  data-structure  holding  the  set  of  pointers  from 
the  old  generation  to  the  new). 

An  alternative  approach  would  be  to  use  Hoare  logic  [8]  to  show  the  correctness  of 
the  low-level  code  and  then  provide  a  type-safe  interface  to  it.  But  it  is  not  clear  how 
the  two  would  interact,  especially  when  the  low-level  code  might  be  spread  over  a  lot 
of  code,  as  is  the  case  for  the  code  that  maintains  the  remembered-set  in  the  mutator. 
Furthermore  as  we  start  to  encode  more  properties  into  our  type  systems  than  basic  type- 
safety,  the  difficulties  we  are  seeing  here  will  start  to  appear  for  more  mundane  code 
as  well.  This  tendency  can  already  be  seen  in  the  Vault  project  which  uses  an  approach 
taken  from  alias-types  to  prove  other  properties  of  their  code  than  just  type-safety. 

The  present  work  is  thus  an  attempt  to  provide  a  middle  ground  between  Hoare  logic 
and  simple  type-systems.  Additionally  to  the  above  stated  goals,  we  make  the  following 
contributions: 

-  A  language  that  can  seamlessly  combine  the  benefits  of  traditional  intuitionistic 
references  and  linear  references  at  the  same  time. 

-  We  introduce  type  cast  and  strong  update  operations  that  work  in  the  absence  of 
any  static  aliasing  information. 

-  The  language  also  offers  the  ability  to  iterate  over  the  objects  contained  in  a  se¬ 
quential  area  of  memory. 

-  We  show  how  the  technique  described  in  [16]  of  using  the  calculus  of  inductive 
constructions  (CiC)  as  our  type  language  to  track  other  properties  than  just  type- 
safety  can  be  used  to  track  properties  of  state. 

Section  2  introduces  the  problem  of  cyclic  data-structures  as  well  as  two  type  sys¬ 
tems  on  which  our  work  is  built.  Section  3  presents  the  problems  that  have  pushed  us 
to  develop  this  system.  Section  4  describes  our  new  language.  Section  5  shows  how  we 
use  it  to  write  a  generational  GC.  We  then  discuss  related  work  a  conclude. 


2  Background 

2.1  Cyclic  structures 

In  the  course  of  writing  the  copy  routine  of  a  garbage  collector,  we  discovered  that  al¬ 
though  current  type  systems  can  handle  the  case  where  the  graph  is  acyclic,  generalizing 
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the  code  to  properly  handle  cycles  proves  difficult.  After  experimenting  with  various  al¬ 
gorithms,  it  became  clear  that  the  problem  is  more  fundamental:  current  type  systems 
are  unable  to  type-check  generic  code  that  can  build  arbitrary  cyclic  data-structures. 

To  see  this,  let  us  look  at  a  classic  example,  a  datatype  for  doubly-linked  lists: 

datatype  a  dlist  =  Node  of  a  *  a  dlistref*  a  dlistref 

The  SML  type  system  allows  us  to  declare  this  datatype  and  write  functions  to  manip¬ 
ulate  it,  but  does  not  offer  us  any  way  to  create  such  an  object:  we  need  a  base  case.  So 
let  us  take  another  example,  with  a  base  case: 

datatype  a  tree  =  Node  of  a  |  Branch  of  a  tree  ref  *  a  tree  ref 

This  time,  we  can  construct  such  trees  since  we  do  have  a  base  case,  but  only  if  we 
have  an  object  of  the  proper  type  a.  More  specifically,  in  order  to  create  a  cyclic  data- 
structure,  we  always  need  a  base  case  to  start  from,  even  if  the  data-structure  we  want  to 
get  in  the  end  does  not  contain  any  node  of  this  base  case  any  more.  Which  means  that 
a  generic  routine  such  as  an  unpickler  or  a  copying  GC  needs  to  be  able  to  construct 
from  scratch  the  base  case  of  any  type  that  could  be  involved  in  a  cyclic  data-structure. 
In  the  tree  example  above,  that  means  creating  a  Node  of  a  for  any  a.  Clearly  this  is 
not  possible. 

OCaml  provides  special  support  to  build  cyclic  data-structures  such  as  the  dlist  ex¬ 
ample  above  using  a  construct  similar  to  val  rec  n  =  Node(0,n,n).  This  helps  for 
specific  code,  but  is  of  no  use  for  generic  code  since  it  only  works  for  pre-determined 
cycles,  whereas  a  copying  GC  simply  does  not  even  know  when  it  is  creating  cycles. 

Type  systems  that  can  decouple  allocation  from  initialization  are  key  to  solving  this 
problem,  but  none  of  the  systems  developed  so  far  are  sufficiently  flexible  to  handle  the 
case  of  a  generic  function  such  as  unpickle.  More  specifically,  none  of  them  know  how 
to  handle  the  case  where  the  pointer  to  the  allocated  object  escapes  (i.e.  is  passed  around 
and  stored  at  arbitrary  locations)  before  the  object  is  initialized:  when  we  allocate  a  new 
object,  we  obviously  know  its  one  and  only  alias,  but  we  cannot  initialize  it  because 
some  of  the  values  might  not  exist  yet,  and  by  the  time  we  are  done  unpickling  the 
children  such  that  initialization  can  take  place,  there  can  be  any  number  of  aliases  and 
we  do  not  statically  know  them  because  the  function  is  generic. 

In  order  to  type-check  a  practical  copying  GC,  we  need  a  new  type  system  that 
is  able  to  update  the  type  (e.g.  from  uninitialized  to  initialized)  of  all  the  aliases  to  a 
particular  object  even  when  those  aliases  are  not  statically  known. 


2.2  Regions 

Region-based  type  systems  [18,  3]  are  the  most  practical  systems  offering  type-safe 
explicit  memory  management.  They  provide  a  solution  to  the  problem  of  safe  deallo¬ 
cation,  with  a  minimum  of  added  constraints.  Even  though  they  do  not  offer  any  help 
when  trying  to  type-check  low-level  code  such  as  object  initialization,  their  practicality 
makes  them  very  attractive  as  a  starting  point.  The  idea  behind  region  calculi  is  to  man¬ 
age  memory  at  the  level  of  regions  (groups  of  objects),  to  annotate  the  type  of  every 
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{kinds)  k 

■-  n  |  r 

{heap  type) 

4'  :: 

{regions)  p 

:=  r  |  v 

{type  env) 

T  :: 

{types)  o 

:=  t  int  a  X  d  a  at  p 

{kind  env) 

A  :: 

1  V[A]{0}(cr)  — >  0 

{region  env) 

0  :: 

{values)  v  ::=  x\i\{v,v)  \  v.n  |  A[A]{0}(r).e 

{operations)  op  ::=  v  \  itiV  |  put[p]  v  |  get  v 

{terms)  e  ::=  u[cr](-iT)  |  halt  v  let  x  =  op  in  e  |  set  v  :=  v;  e 

\  let  r  =  newrgn  in  e  |  freergn  p;  e 


Fig.  1.  Syntax  of  a  region-based  language. 


pointer  with  the  region  that  it  references,  and  to  only  provide  bulk  deallocation  of  a 
whole  region  at  a  time. 

Figure  1  shows  how  such  a  language  might  look  like:  put[p]  v  allocates  v  in  region 
p;  get  v  dereferences  v,  newrgn  creates  a  new  region  and  freergn  deallocates  it;  v.n  is 
a  pointer  to  the  nth  object  in  region  v  created  by  put  and  has  type  a  at  v  if  the  object 
referenced  has  type  cr  (i.e.  \k( v.n )  =  a).  Functions  have  type  V[A]{0}(<j)  — *  0;  they 
are  fully  closed  and  we  use  continuation  passing  style,  so  they  never  return  (hence  the 
— >  0  in  the  type);  A  is  the  list  of  type  (and  region)  parameters;  0  lists  the  regions  that 
need  to  be  live  at  the  time  of  the  call;  and  a  lists  the  type  of  the  value  parameters.  A 
function  call  v[<j\{v)  passes  types  a  and  values  v  to  function  v.  1 

Here  is  a  sample  function  that  creates  a  cyclic  node  of  the  tree  datatype  presented 
previously,  assuming  the  language  has  been  extended  with  support  for  datatypes: 

mktree[r,  t){r}{x:t,  k  :  V[r,  f]{?’}((tree  f)  at?’)  — >  0) 

=  let  n  =  put[r]  (Node  x )  in 
set  n  :=  Branch  n  n;  k[r ,  t ]  (n) 

The  function  is  parameterized  over  type  t  and  region  r  and  expects  an  argument  x  of 
type  t  (which  is  only  used  temporarily  to  create  the  dummy  Node)  and  a  continuation 
argument  k.  The  put  operation  does  the  allocation  while  the  set  operation  does  the 
initialization.  The  (omitted)  kind  of  r  is  R  and  the  kind  of  t  is  Q.  If  k’s  type  had  {}  in 
place  of  {r},  it  would  force  us  to  deallocate  the  region  r  before  calling  it  and  it  would 
make  n  into  a  dangling  pointer,  which  is  allowed  because  liveness  of  the  region  is  only 
needed  and  checked  when  dereferencing  with  get. 

2.3  Alias  types 

The  alias-types  system  [17,  20]  was  developed  precisely  to  handle  low-level  code  such 
as  object  initialization,  memory  reuse,  and  safe  deallocation  at  the  object  level.  To  do 
that,  the  type  of  pointers  is  changed  to  carry  no  information  about  the  type  of  the  refer¬ 
enced  object.  Instead,  the  type  of  a  pointer  is  just  the  location  it  is  pointing  to,  so  it  does 

1  Region  calculi  are  not  necessarily  using  fully  closed  functions  and  continuation  passing  style 
like  we  do  here,  but  a  direct-style  presentation  is  more  complex,  as  is  the  correct  treatment  of 
closure  allocation. 
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(kinds)  k  ::=  A  |  Heap  |  Loc 
(locations)  p  ::=  r  \  v 
(types)  a  ::=  t  |  int  |  v 

|  V[A]{0}(it)  -  0 


(type  env)  T  ::=  •  |  T ,x:cr 
(kind  env)  A  ::=  •  |  A  ,t:K 
(mem  env)  0  ::=  •  |  0,  p\—*  (a, ...,  a) 


(values)  v 

(operations)  op 
(terms)  e 


x\i\v\  A[A]{0}(r).e 

V  |  TViV 

v[d\(v)  |  halt  v  |  let  x  =  op  in  e  |  set  mv  :=  v;  e 

let  (r,  *)  =  new  n  in  e  |  free  p;  e 


Fig.  2.  Syntax  of  an  alias-types  language. 


not  need  to  change  when  the  location’s  type  or  liveness  changes.  While  it  provides  a  lot 
of  power  when  dealing  with  low-level  code,  it  relies  on  an  amount  of  static  information 
which  is  rarely  available  in  general  and  definitely  not  available  in  our  copying  GC. 

Figure  2  shows  the  syntax  of  a  very  simple  alias-types  language.  It  can  be  thought 
of  as  a  region-based  language  where  the  pointers  can  only  point  to  regions  rather  than 
to  objects  inside  them  and  where  regions  have  been  turned  into  tuples,  put  and  get  have 
disappeared  and  the  environment  'F  mapping  locations  to  their  types  has  been  merged 
into  0.  When  dereferencing  a  pointer  of  type  p,  we  thus  have  to  check  the  liveness  and 
the  type  of  the  corresponding  location  by  looking  up  p  in  0.  let  (r,  x)  =  new  n  in  e 
allocates  a  new  object  of  size  n  and  returns  the  location  as  both  a  value  x  and  a  type  r. 
We  could  also  have  done  this  for  regions  so  as  to  distinguish  between  the  region  type 
and  the  region  value  passed  to  put  at  runtime,  but  we  conflated  the  two  for  simplicity. 

Here  is  a  sample  code  that  takes  a  value  of  type  t  and  creates  an  infinite  list  of  this 
element  (a  1 -element  circular  list): 

mklist[e,t]{e}(x  :  t,  k:  V[e,  t,  r]{e,  r  i— >  (t,  r)}(r)  — ■>  0) 

=  let  (r,  n)  =  new  2  in 

set  non  :=  x\  set  n\ n  :=  n;  k[e,  t,  r](n) 


The  argument  e  has  kind  Heap  and  means  that  the  function  accepts  an  arbitrary 
heap  as  input,  whereas  the  type  of  the  continuation  k  shows  that  the  returned  heap  is  e 
extended  with  a  circular  node  at  location  r.  Since  new  only  knows  about  the  size  of  the 
object,  it  can  only  do  allocation  and  the  type  at  location  r  is  originally  set  to  (int,  int) 
and  is  then  incrementally  updated  by  each  set  operation  to  (t,  int)  and  then  (t,  r). 

The  ability  to  update  a  location’s  type  is  the  key  power  of  alias-types.  But  for  that  it 
relies  crucially  on  the  fact  that  the  type  system  should  be  able  to  keep  track  of  pointer 
values.  In  particular,  the  types  need  to  statically  but  precisely  describe  the  shape  of  the 
heap.  Witness  the  fact  in  the  above  example  that  the  type  of  the  circular  list  is  not  just 
listt  but  instead  explicitly  describes  a  1 -element  cycle  and  thus  disallows  any  other 
shape.  The  type  language  of  [20]  is  much  richer  than  what  we  show  here,  but  that  does 
not  help  when  the  shape  of  the  heap  is  simply  not  known  statically. 
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2.4  Calculus  of  constructions 

The  calculus  of  inductive  constructions  (CiC)  [14]  that  we  use  as  our  type  language  is 
an  extension  of  the  calculus  of  constructions  (CC)  [2],  which  is  a  higher-order  typed 
logic.  CC  can  encode  Church’s  higher-order  predicate  logic  via  the  Curry-Howard  iso¬ 
morphism  [9].  Understanding  the  details  of  this  language  is  not  necessary  for  this  paper. 
Suffice  it  to  say  that  it  is  a  powerful  typed  A-calculus  where  A-terms  have  types  of  the 
form  I  la; ;  <p.  ip  which  subsume  both  the  usual  arrow  and  the  universal  quantifier.  Its  in¬ 
ductive  definitions  are  like  datatypes,  with  elimination  constructs  which  combine  case 
analysis  with  a  fixpoint  operation.  To  know  a  bit  more  about  CiC,  see  the  appendix  A. 

3  Motivating  example 

The  simple  type -preserving  GCs  developed  until  now  have  a  few  important  limitations. 
The  most  important  one  is  that  cyclic  garbage  is  not  properly  collected.  Another  lim¬ 
itation  is  that  generational  collectors  do  not  allow  the  mutator  (i.e.  the  code  that  uses 
the  GC)  to  create  references  from  the  old  region  to  the  young  via  destructive  assign¬ 
ment.  We  want  to  lift  those  two  restrictions,  since  they  make  those  type -preserving  GCs 
impractical. 

3.1  Simple  type-preserving  GC 

The  basic  idea  of  a  type-preserving  GC,  proposed  by  Wang  and  Appel  [22],  is  to  layer 
a  stop&copy  collector  on  top  of  a  region  calculus,  where  the  whole  heap  is  placed  in 
a  single  region  and  where  the  copy  function  copies  the  heap  from  the  from  region  to  a 
new  to  region  and  then  frees  the  from  region. 

Because  the  type  of  the  heap  contains  region  annotations  which  will  necessarily 
be  different  before  copying  than  after,  the  copy  function  cannot  just  be  of  type  t  — >  t 
but  instead  has  to  be  of  the  form  MF(t)  — >  MT(t)  where  t  represents  what  should 
be  preserved  while  the  M  type  function  annotates  it  with  details  that  the  mutator  does 
not  care  about.  Furthermore,  in  order  to  work  correctly,  the  copy  routine  might  require 
things  like  tag  bits,  mark  bits  or  in  case  of  generational  GC  it  will  need  to  make  sure  the 
mutator  obeyed  the  generation  barriers  and  provides  a  correct  remembered  set.  All  those 
added  constraints  will  need  to  be  somehow  encoded  in  M  since  copy  has  obviously  no 
control  over  t . 

A  good  way  to  look  at  it  is  that  t  is  a  high-level,  GC-oblivious  type  of  the  heap, 
while  Mp(t)  is  the  low-level  representation  with  all  the  added  details  necessary  for 
the  correct  functioning  of  the  GC.  The  two  will  generally  not  be  of  the  same  kind;  t 
might  for  example  correspond  to  the  type  used  in  the  high-level  source  language  of  the 
mutator  code. 

The  simplest  case  is  a  bare-bones  stop&copy  GC  with  a  source  language  that  only 
supports  integers  and  pairs.  M  might  then  look  like  the  following,  where  R  is  the  current 
region  holding  the  heap: 

Mr{ int)  =>  int 

Mr(t i  x  r2)  =>  (Mfi(n)  x  Mr(t2 ))  at  R 
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In  the  case  of  a  2-generation  collector,  the  heap  will  be  spread  over  2  regions:  Y  for 
the  nursery  and  O  for  the  old  generation.  M  will  now  have  to  enforce  that  there  cannot 
be  any  pointer  back  from  O  to  Y  by  only  allowing  (Mq x  Mo,y(t 2))  at  Y  and 

(Mo,o(t 1)  x  -Wo, 0(7 2))  at  O: 

M0,a{ int)  =>  int 

M0,a(ti  x  72 )  =>  3r  e  {O,  A}.(Mo,r(Ti)  x  Mo,r(T2))  at  r 

In  this  definition,  A  is  expected  to  be  either  equal  to  O  or  Y  depending  on  whether 
pointers  to  Y  are  allowed  at  this  place. 

3.2  Generational  collection 

We  want  to  create  a  simple  yet  usable  type-preserving  generational  GC.  In  order  to  be 
usable,  it  needs  to  be  able  to  properly  handle  cycles  in  the  heap  and  it  needs  to  allow 
the  mutator  to  use  destructive  assignment,  even  if  that  means  creating  pointers  back 
from  the  old  generation  to  the  nursery.  The  traditional  way  to  deal  with  such  pointers 
is  to  keep  track  of  all  of  them  in  a  remembe red-set,  but  for  simplicity,  we  will  restrict 
mutability  to  ref-cells,  as  is  done  in  SML,  and  place  all  those  ref-cells  in  a  separate 
region  which  will  thus  play  the  role  of  a  degenerate  remembered-set. 

Compared  to  the  situations  outlined  in  the  previous  section,  the  heap  is  now  spread 
over  three  regions:  Y  for  the  nursery,  O  for  the  old  generation  and  R  for  the  ref-cells. 
So  that  the  collection  of  Y  can  take  place  without  having  to  scan  O,  we  need  to  make 
sure  that  there  is  no  pointer  from  O  to  Y .  I.e.  pointers  from  Y  and  R  can  point  to  any 
of  Y,  O  or  R  but  pointers  from  O  can  only  point  to  O  or  R.  Our  M  type  function 
which  maps  high-level  types  to  their  low-level  representation  will  again  have  to  enforce 
this  constraint.  If  our  high-level  types  include  integers,  ref-cells  and  pairs,  M  could  be 
defined  as  follows: 

My,r,o, a  (int)  =>  int 

My,R,o,A^Qf  t)  =>  My,r,o,y{t)  at  R 

My,r,o,a(ti  x  r2)  =>  3rG{0,A}.(MY,R,o,r(Ti)  x  MYtRto,r(T2))  at  r 

Here  A  is  expected  to  be  either  equal  to  O  or  to  Y  and  MYro,a{t\  x  t2)  is  the  type  of 
a  pair  that  can  be  allocated  either  in  O  or  in  A  and  whose  children  (and  grand-children, 
etc...)  might  also  refer  additionally  to  R  or  to  Y . 

The  GC  code  that  copies  objects  from  the  nursery  Y  to  the  old  space  O  takes  the  type 
of  the  heap  t,  the  regions  Y,  O,  and  R,  and  the  heap  itself  h :  MY.R.o,Y{t)  as  well  as  a 
continuation  k.  It  first  copies  everything  reachable  from  the  root  h  (but  only  within  Y)  to 
O.  Then  scans  all  the  ref-cells,  considered  as  extra  roots,  and  copies  anything  reachable 
from  them  as  well.  Finally,  it  frees  Y  and  creates  a  new  nursery  before  returning  to  the 
continuation  k.  It  could  look  like  the  following: 

GC[t :  fr]{y,  R,  0}(h:MYtRtOiY(t),k:. . . ) 

=  let  h  =  copy[t ,  y,  R ,  0\  (h)  in 
let  t',x  =  first  R  in 
let  _  =  redirect[t',  Y,  R,  0](x)  in 

freergn  Y\  let  Y  =  newrgn  in  k[Y,R,0\(h) 
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where  the  copy  function  should  simply  do  a  generic  deep  copy,  but  only  within  the 
bounds  of  Y  and  the  redirect  function  should  scan  the  R  region,  redirecting  any  pointer 
to  the  Y  region  to  a  copy  of  that  object  in  ().  The  type  of  the  new  root  pointer  h  returned 
by  copy  can  be  described  as  MY,R,o,o(t)- 

In  order  to  be  able  to  free  Y  at  the  end  of  the  collection,  we  need  to  keep  track 
somewhere  at  the  type-level  of  the  fact  that  pointers  in  R  that  have  been  redirected  can 
only  point  to  O  or  to  R  but  not  to  Y  any  more.  Indeed,  as  the  redirection  is  taking  place 
the  type  of  h  keeps  changing  gradually  until  the  end  when  it  becomes  equivalent  to 
Mo,R,o,o{t)  and  thus  independent  from  Y.  If  b  is  the  boundary  between  what  has  been 
redirected  and  what  has  not,  then  we  can  write  h  \  Cy,r,o ,0 ,b{^)  where  C  is  defined  as: 

CV,i?,o,A,b(mt)  =>  int 

Cy,r,o,aA ref  r)  =>■  let  r  =  if  ( before  b)  OY  in  CY,R,o,r,b(T )  at  R 

CY,R,0,A,b(Tl  x  t2)  =>  3 r€  {O,  A}.(CY,R,0,r,b{Tl)  X  ^Y,R,0,r,b(T^))  a*  T 

This  is  almost  the  same  as  the  previous  M,  except  for  the  added  b  parameter  and  the  case 
of  ref  where  the  object  reachable  from  the  ref-cell  will  have  either  type  Cy^r  o,oAt) 
°r  Cy,r,o,yAt)  depending  on  whether  they  have  been  redirected  or  not. 

The  above  presentation  is  sloppy  and  simplistic  but  already  requires  unusual  fea¬ 
tures  from  the  language: 

-  The  before  b  test  in  the  definition  of  CY,R,o,A,b(re^  r)  obviously  needs  to  know  not 
just  the  region  in  which  the  object  is  located  but  its  actual  location,  which  implies 
that  object  locations  need  to  be  reflected  in  the  pointer  type. 

-  The  new  operation  first  (as  well  as  ifnext  which  will  be  needed  inside  redirect ),  that 
allows  the  code  to  scan  the  region  R,  should  return  both  a  new  pointer  x  and  a  new 
type  if  where  x  is  expected  to  be  of  type  CY,R,o,Y,b(t')-  But  this  is  only  safe  if  we 
know  that  all  objects  in  the  relevant  section  have  a  type  of  the  form  Cy.r,o,y, &(t)- 

-  Since  the  type  of  h,  indexed  by  the  boundary  b  keeps  changing  as  the  boundary 
moves,  we  need  to  be  able  to  update  its  type  when  the  assignment  x  :=  copy[. .](..) 
moves  the  boundary,  even  though  we  do  not  know  anything  about  the  aliasing  rela¬ 
tionship  between  x  and  h. 

The  exact  same  three  issues  appear  when  trying  to  write  a  Cheney-style  stop&copy 
GC  where  the  to  region  is  used  as  a  queue  and  needs  to  be  scanned  and  redirected  in 
very  similar  ways. 

4  Typed  regions 

Our  new  system  of  typed  regions  solves  all  of  those  problems.  It  can  be  thought  of  as 
a  hybrid  between  alias-types  and  the  calculus  of  capabilities  [3]  supplemented  with  the 
calculus  of  inductive  constructions  (CiC),  similarly  to  A#  [16].  Where  alias-types  rely 
on  a  linear  map  of  live  locations’  types  and  the  calculus  of  capabilities  relies  on  a  linear 
set  of  live  regions,  we  rely  on  a  linear  map  of  regions’  types. 

In  a  typical  region  calculus,  the  type  of  the  object  reachable  from  a  pointer  (its 
target)  is  entirely  given  by  the  type  of  the  pointer.  In  contrast,  in  the  alias-types  system, 


(kinds)  k 

:=  $7  |  R  K  |  K  — *  K 

(heap  type) 

'k  ::=  • 

(regions)  p 

:=  r  |  v 

(type  env) 

T  • 

(types)  a,  tp,  r 

:=  1 1  int  |  o  x  o  |  r  at  p.n 

(kind  env) 

A  ::=  • 

V[A]{0}(a)  -  0 

(region  env) 

0  ::=  • 

(values)  v 

:=  x  |  *  |  (v,v)  |  v.n  \  A[A]{0}(T) 

e 

(operations)  op 

:=  v  |  niv  |  put[p,  r]  v  \  get  v 

(terms)  e 

:=  u[p](u)  |  halt  v  |  let  x  =  op  in  e 

c p 

\  set  v  ~  v;e 

j  let  r  =  newrgn  <p  in  e  |  freergn  p- e 


'3/,  v.n  i — *  t 
T  ,x:a 
A  ,t:n 

e,p*->(ip,n) 


Fig.  3.  Syntax  of  the  core  of  our  language. 


the  type  of  the  pointer  does  not  provide  any  direct  information  about  the  type  of  the 
target;  instead,  the  target’s  type  is  kept  in  a  linearly  managed  type  map  indexed  by  the 
pointer’s  type,  which  is  the  singleton  type  holding  the  object’s  location.  Our  new  type 
system  mixes  the  two,  such  that  the  pointer’s  type  holds  both  the  location  and  some 
information  (called  the  intended  type )  about  the  object  to  which  it  points,  while  the 
remaining  information  is  kept  in  a  map  of  regions’  types.  The  type  of  a  region  is  a 
function  that  maps  an  object’s  location  and  its  intended  type  to  its  actual  type. 

4.1  Overview 

The  syntax  of  a  trimmed  down  version  of  our  language,  shown  in  Fig.  3,  looks  like  the 
simple  region  calculus  presented  before,  except  for  the  following  differences: 

-  The  region  environment  0  now  contains  not  only  a  list  of  live  regions,  but  a  map 
from  live  regions  to  their  type  ip  and  size  n. 

-  Pointer  types  have  the  form  r  at  p.n  rather  than  just  a  at  p,  where  n  is  the  offset 
inside  the  region.  Such  a  pointer  does  not  point  to  an  object  of  type  r.  Instead,  we 
force  an  indirection  through  the  regions’  type  such  that  the  target’s  type  is  0(p)  n  r. 
Think  of  r  as  the  intended  type  of  the  location  while  @(p)  maps  those  intended 
types  to  their  actual  value  at  any  particular  time. 

-  The  region  kind  now  takes  a  parameter  k.  If  p :  R  k,  then  the  region’s  type  will  be 
of  kind  Nat  — ■>  k  — >  O  and  the  term  r  in  r  at  p.n  will  have  to  have  kind  k. 

-  Just  as  before,  a  value  v.n  has  type  ('T(V.n))  at  v.n  but  'l'(y.n)  can  now  be  of  any 
kind  rather  than  only  O . 

-  put  takes  an  additional  parameter  r  and  returns  a  pointer  of  type  r  at  p.n  after 
checking  that  v :  0(p)  n  r. 

-  set  is  now  a  strong  update:  it  changes  the  type  of  the  location  to  p>  which  has  kind 
k  — ►  Cl.  This  type  needs  to  be  provided  because  there  are  many  valid  choices  and 
they  are  not  all  equivalent. 

-  newrgn  now  takes  a  parameter  ip  which  is  the  initial  type  of  the  region. 

A  region’s  type  @(p)  which  ignores  the  location  parameter  n  corresponds  to  a  clas¬ 
sical  intuitionistic  region  system  where  aliases  cannot  be  distinguished;  pointer  types 
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will  then  typically  be  of  the  form  3 n.T  at  p.n  since  static  tracking  of  n  is  unnecessary. 
On  the  other  hand,  if  the  type  ignores  the  r  parameter,  then  it  enjoys  properties  more 
like  those  of  linear  systems  such  as  alias-types:  you  have  to  statically  keep  track  of  the 
exact  location  n,  you  can  abstract  away  the  intended  type  by  using  3 t.t  at  p.n,  and  you 
can  change  the  type  of  a  location  without  any  regard  to  its  previous  use.  The  strength 
of  our  system  resides  in  the  fact  that  we  can  choose  at  any  point  from  a  continuum  of 
options  between  those  two  extremes. 

As  mentioned,  this  system  solves  the  three  problems  we  have  encountered  when 
trying  to  code  our  generational  GC:  The  before  b  test  can  simply  compare  b  to  the  offset 
n  of  the  pointer  since  it  is  now  carried  in  its  type;  Since  all  objects  in  a  region  have  a  type 
of  the  form  O(p)  n  t,  setting  the  region’s  type  to  something  like  C  makes  sure  that  first 
indeed  returns  a  pointer  to  an  object  of  type  C(t );  Finally,  since  0  is  managed  linearly 
and  since  all  memory  accesses  have  to  look  up  the  target’s  type  in  0,  we  can  globally 
update  the  type  of  objects  when  we  move  the  boundary  by  updating  the  corresponding 
type  in  0. 

4.2  The  language 

The  syntax  of  the  full  language  is  shown  in  Fig.  4.  The  language  uses  continuation 
passing  style  and  fully  closed  functions,  sort  and  ptm  together  form  the  pure  type  system 
corresponding  to  CiC.  All  our  types  are  actually  terms  of  this  language  and  fi  is  actually 
defined  as  an  inductive  definition  in  CiC.  M,  T,  F,  A,  0  are  environments  used  in  the 
typing  rules. 

The  region  spec  stored  in  the  region  environment  0  is  either  the  type  of  the  region 
together  with  its  size  (p,  n)  or  the  set  of  regions  for  which  this  region  can  be  an  alias. 
This  is  used  when  it  is  not  statically  known  into  which  region  a  reference  will  point,  in 
which  case,  the  reference  will  have  type  3 rGp.r  at  r.n. 

Values  can  be  integers,  pairs  ((i>,  v)  :o  x  er),  references  ( v.n :  r  at  v.n),  existential 
packages  ((i p,  v)  :3t:  k.o),  region  existential  packages  ((p,  v) :  3r  £  p.a)  and  functions. 
The  terms  do  the  following: 

7 TiV.  select  from  a  tuple. 

put [/?,  r]  v :  allocate  an  object  v  in  region  p. 

get  v :  return  the  object  pointed  to  by  v. 

cast[P]  v:  safely  change  the  type  of  v  according  to  proof  P. 

v[0\{v)'-  make  a  tail-call  to  function  v. 

halt  v:  halt  the  machine. 

let  x :  a  =  op  in  e:  bind  variable  x  as  you  would  expect. 

c p 

set  v  :  =  v,  e:  do  a  strong  update,  p  describes  the  new  type  of  the  location, 
let  r  =  newrgn  p  in  e:  allocate  a  new  region  of  type  p. 
f reerg n  p\  e :  free  the  region  p. 

cast[P]  p  i — ^  p\  e:  safely  change  the  type  of  region  p  to  p,  with  proof  P. 

let  ( t ,  x )  =  open  V  in  e:  unpack  the  existential  v  into  t,  and  x. 

let  (r,  x)  =  openrgn  v  in  e:  unpack  the  region  existential  v  into  r  and  x. 

iffirst  p  (x,t  .  e )  (e):  test  whether  p  is  empty  and  selects  the  corresponding  branch.  If 

non-empty,  x  is  bound  to  a  pointer  to  the  first  object  and  t  to  its  type. 
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(sort)  s  ::=  Kind  j  Kscm  j  Ext 

( ptm )  p,r,K,P  ::=  s\x\\x:p.p\pp\  Hx\p.  p 

\  lnd(a;:v?){<p}  |  Ctor (i,p)  |  Elim {p,p\(p){p} 

(memory)  M  ::=  •  |  M,  v.n  i— >  v 

(heap  type)  ^  ::=  •  |  T,  v_n  >  T 

(type  env)  T  ::=  •  |  T,  x:cr 

(kind  env)  A  ::=  •  |  A  ,t:K 

(region  env)  0  ::=  •  |  @,pi— 

(region  spec)  6  ::=(p,n)\p 

(regions)  p  :  R  n  ::=  r  \  v 

(types)  a:£l  S=  int  |  a  x  a  \  r  at  p.n  \  Eli: k.o  |  3r€p.cr  |  V[A]{@}(<?)  — >  0 

(values)  v  ::=  x  \  i  \  (v,v)  \  v.n  \  (<p,v)  \  ( p,v )  |  A[A]{0}(T).e 

(operations)  op  ::=  v  |  itiV  \  put[p,  r]  v  \  get  v  \  cast[P]  v 

(terms)  e  ::=  v[<p\(v)  \  halt  v  \  let  x:o  =  op  in  e  |  set  v  :=  v;  e 

let  r  =  newrgn  p  in  e  |  freergn  p;  e  |  cast[P]  p  p-e 
|  let  ( t ,  x)  =  open  v  in  e  |  let  (r,  x)  =  openrgn  vine 
|  iffirst  p  (x,t .  e)  (e)  \  ifnext  v+i  (x,  t .  e)  (e) 

Fig.  4.  Syntax  of  the  language 


ifnext  v+i  (x,  t  .  e)  (e):  similarly,  give  a  pointer  to  the  next  object  past  v,  if  any.  i  is 

the  size  of  the  object  pointed  to  by  v  and  thus  skipped  by  the  operation. 

We  have  decided  to  manipulate  whole  objects  rather  than  words  and  not  to  split 
allocation  from  initialization.  It  is  easy  to  change  the  language  to  provide  alloc,  load, 
and  store  instead  of  put,  get,  and  set,  but  the  typing  rules  become  more  verbose  and 
so  does  the  code  in  our  examples. 

The  operational  semantics  of  the  language  are  shown  in  Fig.  5.  The  machine  state 
is  define  as  the  4-tuple  (M :  0:  'T:  e)  where  0  is  only  used  when  checking  the  size  of  a 
region  in  iffirst  and  ifnext,  and  T  is  only  used  to  provide  the  type  of  the  pointer  in  those 
same  two  operations.  Instead  of  checking  the  size  in  0,  we  could  look  up  M (v.n)  to 
see  if  it  exists,  which  would  get  us  rid  of  0,  but  that  would  move  us  further  away  from 
a  realistic  implementation. 

The  typing  rules  are  given  in  the  appendix,  together  with  statements  of  type  sound¬ 
ness  and  complete  collection  properties. 

5  Generational  collection 

As  suggested  earlier,  we  will  use  a  simple  form  of  generational  collection,  so  as  to  side¬ 
step  the  issue  of  keeping  track  of  the  back  references  from  the  old  generation  to  the 
nursery.  So  our  source  language  is  restricted  to  the  following  types:  integers,  immutable 
pairs,  reference  cells. 
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(M;  0;  »P;  v.n[Xp]A)) 

where  M(y.n)  =  A[t :  kJIO'K* :  &).e 
(AT;  0;  <P;  let  x  =  v  in  e) 

(M;  0;  VP;  let  x  =  7rj(ri,  x2)  in  e) 
(M;0,l/i->(¥>,n);3r; 

let  a;  =  put[n,  r]  v  in  e) 

(M ;  0;  let  x  =  get  v.n  in  e) 

(M;  0;  'P;  let  x  =  cast[P]  v  in  e) 
(M;0;^;let  (t,x)  =  open  (ip,  v)  in  e) 
(M ;  0;  »P;  let  (r,  x)  =  openrgn  (v,  v)  in  e) 

(M ;  0;  'P;  let  r  =  newrgn  p  in  e) 

(M;  0;  »P;f reerg n  v;e) 

(AT;  0,  vi-^(p' ,  n);  >P;  cast[P]  1 — e) 
(M;  0,  vt-^(p',  n')\  >P;  set  v.n  :=  v ;  e) 
(M;  0;  'P; 

iffirst  v  (x,t .  ei)  (e2)) 

(AT;  0;  'P; 

ifnext  n.n-M  (x,t  .  ei)  (e2)) 


(A/;  0;  \P;  e[<p,  v/t,  x\) 

{M;  0;  \P;  e[v/x\) 

(Af;  0;  \P;  e[vi/x\) 

( AT ,  n.n  1 — *  v\  0,  i/H- >  (<p,  n+1); 

VP,  n.n  1— >  r;  e[n.n/x]) 

(AT;  0;  <P;  e[AT(t/.n)/x]) 

(M;  0;  'P;  e[x/x]) 

(AT;  0;  <P;  e[<p,  v/t,  x]) 

(M;  0;  'P;  e[v,  v/r,  x]) 

(AT;0,n  >-►  (p,  0);  >P;  e[v/r\) 
where  v  £  Dom{Q) 

(AT\n;  0\n;  \ P\n;e) 

(A/;  0,  vi— >  (ip,  n);  VP;  e) 

(A/,  n.n  1 — >  v;  0, ni— >  (upd  p'  n  p,  n')\  <P;  e) 

if  0(v)  =  (<p,0) 
where  'P(n.O)  =  r 

if  O(v)  =  (p,n+ 1) 
where  'P(^.n+ 1)  =  r 


(M;0;*;ea) 

(A/;  0;  VP;  ei[r,  n.O/t,  x]) 

(A/;  0;  VP;  e2) 

(A/;  0;  »P;  ei[r,  v.n+l/t,  x]) 


Fig.  5.  Operational  semantics  of  the  language. 


We  will  use  three  regions:  O  is  the  old  generation,  Y  is  the  nursery  and  R  contains 
all  the  ref-cells  and  only  ref-cells.  Thus  R  can  act  as  a  degenerate  form  of  remembered 
set.  We  require  that  pointers  from  O  can  only  point  to  O  or  R  but  not  to  Y. 

The  type  of  our  variables  have  the  shape  Mo,r,y(t )  defined  below: 

M0,r,a( int)  =>  int 

Mo,R,A(re fr)  =>  3n:Nat.r  at  R.n 

M0,r,a(ti  x  r2)  =>  3 r  €  {O,  A}3n:  Nat.(ri,  t2)  at  r.n 

The  regions’  types  while  the  mutator  is  running  look  like: 

Y  1— >  An. A(fi,f2). Mo, n,y(ii)  x  Mo.R.yih) 

O  1— >  An.A(fi,  f2).A/(9,n,o(^i)  x  Mo,R,o(h) 

R  1— >  Xn.Xt.Mo,R,Y(t) 

and  while  a  collection  copying  objects  from  Y  to  0  is  in  progress  and  pointers  in  R  are 
redirected  from  Y  to  (),  the  type  of  R  is  the  following: 

R  1— >  An.Ai.l6t  r  —  if  nr  ^  n  thon  (X)  gIsg  f  in  A fo.nx(f) 

The  top-level  code  of  the  GC  code  that  copies  objects  from  the  nursery  Y  to  the  old 
space  O  is  shown  in  figure  6.  We  omit  type  parameters  that  are  obvious  from  context 
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(*  Inductive  definition  of  the  source-level  types.  *) 

Inductive  ilT  :  Kind  :=  inf :  0T  I  ref :  flT  — ►  flT  |  pair :  Or  — >  QT  — >  QT 

(*  Mapping  types  from  source-level  to  low-level.  *) 
typedef  M0,r,a  t  =  case  t  of  int  int 

\reft  =>  3n:  Nat. t  at  r.n 
\  pairti  t2  =>  36 G  {o,  a}3n :  Nat.(ti,  <2)  at  b.n 

(*  Type  of  a  region  holding  tuples,  like  o  and  y.  *) 
typedef  TupRgn  or  a  =  \n.\(t\,t2).M0,rta(ti)  x  M0irya(t2 ) 

(*  Type  of  a  region  holding  ref  cells,  during  redirection.  *) 
typedef  RefRgn  or  y  b  =  An. At. let  a  =  if  (b  >  n)  o  y  in  M0iT,a(t) 

(*  Type  of  the  continuation  passed  to  the  GC .  *) 
typedef  gccont  =  V[j/ :  R  (QT  x  ftT)]{. .  .}(x :  M0^y(t))  —*  0 

(*  A  deep  copy  function  not  shown  here.  *) 
copy  :  V[f  :fT,  b:  Nat, .  .  .]{. .  .}(M0,r,w(f))  — >  M0,r,0(f) 

(*  Main  entry  point,  h  is  the  root  pointer  and  t  is  its  type.  *) 

{y  >—>  (TupRgn  o  r  y ,  my) ,  o  1— >  (TupRgn  o  r  0,mo),r  1— ►  (\n.\t.M0,riy(t),mr)} 

(h :  M0)r,y(t),  k :  gccont) 

=  let  fr  =  copy[t,  0,  y,  r,  o\(h )  in 

iffirst  r  then  x,  t!  .  redirect[t,  0,  t' ,  y,  r,  o\(x,  h,  k )  else  GCtail[t,  y,  r,  o](h.,  k ) 

(*  Code  to  execute  at  the  end  of  GC  when  redirection  is  done.  *) 
GCtail[t  :flT , . . .  ] 

{y  1 — *  (TupRgn  or  y,  my),  o  1— >  ( TupRgn  o  r  o,  m0),  r  1— >  (RefRgn  or  y  mr,  mr)} 

(h :  M0jr}0 (t),k: gccont) 

=  freergn  y. 

let  y  =  newrgn  (A_:  (flT  x  Q.T).  int)  in 
cast[. . .  ]  r  (\n.\t.M0trty(t))\ 
cast[.  -  - ]  J/  1 — *•  (TupRgn  or  y); 
fc[f/](cast[.  .  .  :  Motr,o(t)  <  Mo:r,y(t)]  fl) 

(*  Loop  through  the  ref  cells,  redirecting  ptrs  from  y  to  o.  *) 
(*  h  is  the  root  pointer  that  we  need  to  pass  back  to  GCtail.  *) 
(*  x  is  the  boundary  pointer  that  sweeps  through  r.  *) 
redirect [f  :flT,  b:  Nat,  t' :  S!r, . . .  ] 

{y  1 — ►  (TupRgn  or  y,  my),  o  1— >  (TupRgn  or  o,  m0),  r  (RefRgn  or  y  b,  mr)} 

(x:t  at  r.b,  h:  M0tr,o(t'),  k: gccont) 
m0  r  0 

=  setx  :=’  copy[t,  b,y,r,  o]((y,  get  a;}); 
cast[. . .]  r  *— >  (RefRgn  or  y  (&+1)); 

ifnext  x+1  then  x,  t  .  redirect[t,  b+ 1,  t' ,  y,  r,  o\(x ,  h,  k)  else  GCtail[t,  y,  r,  o](h) 

Fig.  6.  Generational  GC 


and  use  direct-style  rather  than  continuation  passing  style  where  convenient,  to  make  the 
code  more  readable.  The  code  of  the  copy  function  is  not  shown  and  requires  additions 
to  our  language  which  are  outside  the  scope  of  this  paper. 
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Since  the  types  of  regions  themselves  refer  to  those  regions,  there  is  a  circularity 
problem  when  we  create  a  region  that  prevents  us  from  creating  the  region  with  its 
proper  type.  In  GCtail  we  show  how  to  work  around  this  problem  using  cast:  we  first 
create  Y  with  a  dummy  type,  and  then  cast  it  to  the  desired  type  (the  proof  needs  to 
show  that  the  new  type  preserves  the  type  of  all  objects  in  the  region;  this  is  trivial  since 
the  region  is  empty).  The  language  could  allow  the  type  of  a  new  region  to  refer  to 
that  new  region,  but  that  would  still  not  help  when  creating  several  regions  whose  types 
refer  to  each  other. 

6  Related  work 

The  calculus  of  capabilities  [3]  was  the  first  calculus  that  tried  to  provide  safe  explicit 
memory  deallocation  while  allowing  dangling  pointers.  The  linear  handling  of  our  re¬ 
gions  was  strongly  influenced  by  that  work.  But  they  did  not  attempt  to  provide  any 
form  of  strong  update  or  to  solve  any  of  the  other  problems  related  to  low-level  mem¬ 
ory  management. 

Alias  types  [17,  20]  also  have  a  lot  in  common.  In  that  work,  strong  update  is  the 
only  form  of  update  available.  Separating  object  initialization  from  allocation  is  very 
easy,  as  is  explicit  deallocation  and  memory  reuse.  But  the  calculus  keeps  the  notion  of 
location  abstract,  preventing  any  reasoning  on  the  relative  position  of  memory  objects. 
Also  the  flexibility  comes  at  the  cost  of  requiring  a  static  description  of  all  the  possible 
aliases  of  the  object  being  assigned  to.  This  information  is  often  simply  not  available. 

The  Vault  language  [4]  takes  the  work  on  alias  types  and  tries  to  both  extend  it  and 
give  it  a  surface  syntax  (so  as  to  enable  to  programmer  to  give  that  needed  aliasing 
information).  In  the  first  paper,  they  mostly  show  how  to  integrate  classical  intuition- 
istic  references  with  alias-types-style  statically  tracked  references.  They  also  show  that 
tracking  references  to  region  objects  allows  an  alias-type  system  to  subsume  a  region 
type  system.  The  main  limitation  compared  to  our  work  is  that  you  have  to  choose  once 
and  for  all  whether  a  reference  should  be  intuitionistic  or  linear  (i.e.  tracked). 

In  the  second  paper  [5]  they  try  to  address  that  limitation  by  introducing  the  notions 
of  adoption  which  allows  the  user  to  make  a  linear  reference  intuitionistic,  and  focus 
which  does  the  converse.  The  implementation  of  adoption  is  unclear  and  seems  some¬ 
what  incompatible  with  a  low-level  language.  As  for  focus,  it  allows  some  of  what  we 
want  (such  as  strong  update  in  the  presence  of  arbitrary  aliasing),  except  for  the  fact  that 
the  restrictions  are  much  too  severe,  especially  the  one  that  requires  the  type  change  to 
be  limited  to  the  scope  of  the  construct. 

In  the  work  on  Typed  Assembly  Language  [12],  the  authors  shows  a  simple  way  to 
handle  the  problem  of  separating  allocation  from  object  initialization,  without  resorting 
to  any  form  of  linearity,  but  this  approach  is  inherently  very  limited  and  does  not  seem 
to  lend  itself  to  any  other  application. 

Wang  and  Appel  [21]  proposed  to  build  a  tracing  garbage  collector  on  top  of  a 
region-based  calculus,  thus  providing  both  type  safety  and  completely  automatic  mem¬ 
ory  management.  Their  type  system  does  not  support  existential  packages,  so  they  have 
to  rely  on  a  closure  conversion  algorithm  that  represents  closures  as  datatypes  [19,  15]. 
This  makes  closures  transparent,  making  it  easy  for  the  copy  function  to  analyze,  but  it 


14 


requires  whole  program  analysis  and  has  major  drawbacks  in  the  presence  of  separate 
compilation.  More  importantly,  their  algorithm  does  not  address  the  problems  linked  to 
cycles  or  generations,  and  only  presents  an  impractical  treatment  of  forwarding  point¬ 
ers. 

Monnier  et  al.  [10]  has  shown  how  to  use  intensional  type  analysis  [7]  to  solve  the 
more  serious  problems  of  Wang  and  Appel’s  work  and  to  extend  it  to  deal  with  a  very 
primitive  form  of  generational  collection,  but  which  does  not  allow  cycles  or  even  any 
form  of  destructive  assignment  on  the  part  of  the  mutator. 

Shao  et  al.  [16]  proposed  to  use  CiC  as  the  type  calculus  of  programming  language 
so  as  to  be  able  to  manipulate  explicit  proofs.  We  reuse  their  idea  with  the  same  purpose 
of  allowing  sophisticated  type  manipulation  and  arbitrary  cast  operations. 

7  Conclusion 

We  have  presented  a  novel  type  system  that  offers  an  unusual  flexibility  to  play  with  the 
typing  of  memory  locations.  This  type  system  offers  the  ability  to  choose  any  mix  of 
linear  or  intuitionistic  typing  of  references  and  to  change  this  choice  over  time  to  adapt 
it  to  the  current  needs.  It  is  able  to  handle  strong  update  of  memory  locations  even  in  the 
presence  of  unknown  aliasing  patterns.  The  reliance  on  CiC  allows  very  sophisticated 
type  manipulations. 

We  have  shown  how  to  use  it  to  solve  the  difficult  problem  of  type  checking  a 
generational  garbage  collector,  including  proper  handling  of  cycles  and  while  allowing 
the  mutator  to  perform  destructive  assignment  on  reference  cells.  We  have  also  shown 
how  to  use  this  same  type  system  to  encode  a  stack  of  activation  records  inside  a  region. 


References 

[1]  A.  W.  Appel.  Foundational  proof-carrying  code.  In  Annual  Symposium  on  Logic  in  Com¬ 
puter  Science ,  pages  247-258,  June  2001. 

[2]  T.  Coquand  and  G.  P.  Huet.  The  calculus  of  constructions.  Information  and  Computation , 
76:95-120,  1988. 

[3]  K.  Crary.  D.  Walker,  and  G.  Morrisett.  Typed  memory  management  in  a  calculus  of  ca¬ 
pabilities.  In  Symposium  on  Principles  of  Programming  Languages ,  pages  262-275,  San 
Antonio,  TX,  Jan.  1999. 

[4]  R.  DeLine  and  M.  Fahndrich.  Enforcing  high-level  protocols  in  low-level  software.  In 
Symposium  on  Programming  Languages  Design  and  Implementation.  ACM  Press,  May 
2001. 

[5]  M.  Fahndrich  and  R.  DeLine.  Adoption  and  focus:  Practical  linear  types  for  imperative 
programming.  In  Symposium  on  Programming  Languages  Design  and  Implementation. 
ACM  Press,  May  2002. 

[6]  N.  A.  Hamid,  Z.  Shao,  V.  Trifonov,  S.  Monnier,  and  Z.  Ni.  A  syntactic  approach  to  foun¬ 
dational  proof-carrying  code.  In  Annual  Symposium  on  Logic  in  Computer  Science ,  pages 
89-100,  Copenhagen.  Denmark,  July  2002. 

[7]  B.  Harper  and  G.  Morrisett.  Compiling  polymorphism  using  intensional  type  analysis.  In 
Symposium  on  Principles  of  Programming  Languages,  pages  130-141,  Jan.  1995. 

[8]  C.  A.  R.  Hoare.  An  axiomatic  basis  for  computer  programming.  Communications  of  the 
ACM,  12(101:576-580,  Oct.  1969. 


15 


[9]  W.  A.  Howard.  The  formulae-as-types  notion  of  constructions.  In  To  H.B.  Curry:  Essays  on 
Computational  Logic,  Lambda  Calculus  and  Formalism.  Academic  Press,  1980. 

[10]  S.  Monnier.  B.  Saha,  and  Z.  Shao.  Principled  scavenging.  Technical  Report  Yale/DCS/1205, 
Yale  University,  2000. 

[11]  S.  Monnier  and  Z.  Shao.  Typed  regions.  Technical  Report  Yale/DCS/1242,  Yale  University, 

2002. 

[12]  G.  Morrisett,  D.  Walker,  K.  Crary,  and  N.  Glew.  From  system  F  to  typed  assembly  language. 
In  Symposium  on  Principles  of  Programming  Languages,  pages  85-97,  San  Diego,  CA,  Jan. 
1998. 

[13]  G.  C.  Necula.  Proof-carrying  code.  In  Symposium  on  Principles  of  Programming  Lan¬ 
guages,  Jan.  1997. 

[14]  C.  Paulin-Mohring.  Inductive  definitions  in  the  system  Coq — rules  and  properties.  In 
M.  Bezem  and  J.  Groote,  editors.  Proc.  TLCA.  LNCS  664,  Springer- Verlag,  1993. 

[15]  J.  C.  Reynolds.  Definitional  interpreters  for  higher-order  programming  languages.  In  Pro¬ 
ceedings  of  the  ACM  annual  conference,  pages  7 17-740,  1972. 

[16]  Z.  Shao,  B.  Saha,  V.  Trifonov,  and  N.  Papaspyrou.  A  type  system  for  certified  binaries.  In 
Symposium  on  Principles  of  Programming  Languages,  pages  217-232,  Portland,  OR,  Jan. 
2002. 

[17]  F.  Smith,  D.  Walker,  and  G.  Morrisett.  Alias  types.  In  European  Symposium  on  Program¬ 
ming,  2000. 

[18]  M.  Tofte  and  J.-P.  Talpin.  Implementation  of  the  typed  call-by-value  A-calculus  using  a 
stack  of  regions.  In  Symposium  on  Principles  of  Programming  Languages,  pages  188-201, 
Jan.  1994. 

[19]  A.  Tolmach  and  D.  P.  Oliva.  From  ML  to  Ada:  Strongly-typed  language  interoperability  via 
source  translation.  Journal  of  Functional  Programming,  8(4):367-412,  July  1998. 

[20]  D.  Walker  and  G.  Morrisett.  Alias  types  for  recursive  data  structures.  In  International 
Workshop  on  Types  in  Compilation,  Aug.  2000. 

[21]  D.  C.  Wang  and  A.  W.  Appel.  Safe  garbage  collection  =  regions  +  intensional  type  analysis. 
Technical  Report  TR-609-99,  Princeton  University,  1999. 

[22]  D.  C.  Wang  and  A.  W.  Appel.  Type-preserving  garbage  collectors.  In  Symposium  on  Prin¬ 
ciples  of  Programming  Languages,  Jan.  2001. 

[23]  B.  Werner.  Une  Theorie  des  Constructions  Inductives.  PhD  thesis,  A  L'Universite  Paris  7, 
Paris,  France,  1994. 


16 


(sort)  s  ::=  Kind  |  Kscm  j  Ext 

(ptm)  ip  ::=  s  \  x  \  \x :  ip.  \  <p  |  Ila: :  (/3.  <p 

Ind(*:v3){^}  |  Cto r  (*,¥>)  j  H\m[ip,tp\(ip){0} 

Fig.  7.  Syntax  of  the  calculus  of  inductive  constructions. 


A  Calculus  of  constructions 

The  syntax  of  CiC  is  shown  in  Fig  7.  The  A  term  corresponds  to  the  abstraction  of  the  A- 
calculus,  and  the  II  term  is  a  dependent  product  type.  When  the  bound  variable  does  not 
occur  in  the  body,  the  product  type  is  usually  abbreviated  as  if  — >  <p.  In  the  terminology 
of  pine  type  systems.  Kind,  Kscm,  and  Ext  are  the  sorts. 

CiC,  as  its  name  implies,  extends  the  calculus  of  constructions  with  inductive  defini¬ 
tions.  An  inductive  definition  can  be  written  in  a  syntax  similar  to  that  of  ML  datatypes. 
For  example,  the  following  introduces  an  inductive  definition  of  polymorphic  lists: 

lnd(List:  Kind  — >  Kind){m7  :  Hx.Listx  |  cons  :  Hx.x  — >  List  x  — >  List  x} 

The  logic  also  provides  elimination  constructs  for  inductive  definitions,  which  com¬ 
bine  case  analysis  with  a  fixpoint  operation.  Objects  of  an  inductive  type  can  thus  be 
iterated  over  using  these  constructs.  In  order  for  the  induction  to  be  well-founded  and 
for  iterators  to  terminate,  a  few  constraints  are  imposed  on  the  shape  of  inductive  defini¬ 
tions;  most  importantly,  the  defined  type  can  only  occur  positively  in  the  arguments  of 
its  constructors. The  calculus  of  inductive  constructions  has  been  shown  to  be  strongly 
normalizing  [23],  hence  the  corresponding  logic  is  consistent. 

In  the  remainder  of  this  paper,  we  will  use  more  familiar  mathematical  notation  , 
rather  than  the  strict  definition  of  CiC  syntax  given  in  this  section.  For  example,  induc¬ 
tive  definitions  will  be  presented  in  BNF  format.  We  will,  however,  retain  the  II  nota¬ 
tion,  which  can  generally  be  read  as  a  universal  quantifier. 


B  Typing  rules 

The  typing  rules  for  the  terms  of  our  language  are  given  here  in  Fig.  9  and  10.  Those 
rules  use  the  two  following  auxiliary  type  functions: 

upd  p  n  tp'  =  Am.Af.if  (m  =  n )  (p' t)  (p  m  t) 

size(a\  x  a 2)  =>  size(cri)  +  size(cr2) 
size(3t  :n.cr)  =>  size(a) 
size(3r£p.a )  =>  size(a) 
size(_)  =>  1 

The  main  judgments  are: 

-  T:  A:  0: 1’  h  v  :  a  if  c  has  type  a  in  the  given  environment. 

-  T:  A:  0:  F  h  e  if  c  is  well-formed  under  the  given  environment. 
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(V  a  a  h  r  h  ¥  Abe  $;0hM) 


h  A 


Ah  t  :  K 


A  h  <7i  :  ff 


h  •  h  A ,t:K 

•  h  ifiij  :  k  •  h  Vi  :  R  k 


Ahio  :ob,...,x„:a„ 
A  h  pi  h->  Oi 


h  r'o-O  h- >  1^00  j  •  ■  •  j  -Tl  1  *  (flmn  A  h  p0  i->  6>0, . . .  ,p„  i->  0„ 
A  hp:  Rk  Ah  pi  :  R  /c  Ahp  :  Rk  Ahp:  Nat  — >  K 


n 


A  h  p\- 


Ahpw((p,  n) 


Vj:0..n  — 1  J;»;»;«h  M(vj.j)  :  <fii  j  (fk^.j))  $;9hM  T;0;»;»he 

'k;  i/0  (<po,n0),  (<pn,nn)  h  M  h  (M;  0;  >5;  e) 

Fig.  8.  Environment  formation  rules. 


-  \k;  A;  0;  T  h  v  i— >  a  if  v  points  to  an  object  of  type  a. 

-  a  <  a'  if  (T  is  a  subtype  of  a'. 

-  0  h  p  £  p  if  pis  indeed  one  of  p. 

-  0  h  0'  if  0'  can  be  used  in  lieu  of  0  because  it  contains  the  same  regions  with  the 
same  types  (but  they  can  differ  w.r.t.  to  region  aliases). 

The  typing  rules  for  environments  are  given  in  Fig.  8  together  with  the  definition  of 
a  well-formed  machine  state  h  (M;  0;  ’T;  e). 

B.l  Properties  of  the  language 

We  state  here  a  few  lemmas  used  in  the  proof  of  type  soundness.  The  proofs  can  be 
found  in  the  companion  technical  report  [11].  Since  our  type  language  is  CiC,  we  know 
it  is  strongly  normalizing  and  confluent. 

The  proofs  of  the  lemmas  below  do  not  present  any  unusual  difficulty,  contrary  to 
what  was  the  case  in  [10]  where  the  widen  operator  introduced  a  lot  of  extra  trouble. 
The  substitution  lemma  for  types  turned  out  to  be  simpler  than  expected  when  substi¬ 
tuting  v  for  r  in  a  0  such  as  {n— >z/,  i/i— > . . .}. 

One  annoyance  is  that  'T;  A;0;T  h  v  :  a  has  to  be  re-proven  each  time  0  is 
changed.  Luckily,  reconstructing  the  new  proof  is  simple  since  0  is  only  used  in  those 
rules  in  order  to  verify  that  the  witness  of  a  package  of  type  3?’  £  p.a  is  indeed  in  p. 

Lemma  1  (Subsumption). 

If  a  <  o'  and  T;  A;  0;  T  h  v  :  a  then  \k;  A;  0;  T  h  v  :  a' . 

Lemma  2  (Deallocation). 

//'k;  A;  0;  T  h  e  and  p  ^  Dom(Q)  then  \k\p;  A;  0;  T  h  e. 

Lemma  3  (Substitution). 

//''k;  A;  0;  T  h  v  :  a  then: 

-  //''k;  A;  0;  T{;r:er}  hi/  :  o'  then  *k;  A;  0;  T  h  v'[v/x\  :  a1. 
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A;  0;  F  h  v  ^  V[f7^] {©'}(?)  -►  0 

•  h  a  :  Uk  0h0'[ff/f]  *F;  A;  0;  T  h  Vi  :  (Ji\B /t\  >p;  A;  •;  T  h  v  :  int 

f:A:0:rh  v[a](v)  'P;  A;.;r  h  halt  v 

'5;  A;  0;  r  I -  v  :  ip  n  t 
'P;  A;  0,  pt—>  (ip,  n+1);  r,  x :  r  at  p.n  h  e 
A;  0,  pi— >  {if. >,  n);  r  h  let  x  =  put[p,  r]  y  in  e 

A;0;r  I-  op  :  a  'F;  A;  0;  T,  x :  a  h  e  _ 'F;  A;  0;  T  h  e _ 

>F;  A;  0;  F  h  let  x:a  =  op  in  e  >F;  A;  0,p h->  (<p,  n);  r  h  freergn  p;  e 

>F;  A;  0,  p  i — ►  (<p',  n);  T  h  e  A  h  p  :  R  k  A  h  <p  :  Nat  — >  k  — >  ft 

Ah?:  Ili:0..n— 1.  lit {p  it)  <  {ip'  it)  A,  r :  R  k;  0,  ri— >  (<p,  0);Thc 

A;  0,  pi-^  {ip,  n);  F  h  cast[P]  p^->  p'\e  'P;  A;  0;  r  h  let  r  =  newrgn  p  in  e 

>5;  A;  0,  pi— >  (p,  n);  T  h  y  :  r  at  p.m 
>3/;  A;  0,  pi— ►  (<p,  n);  T  h  y'  :  <p'  r  size(<p'  r)  =  size{ip  m  t) 

*F;  A;  0,  p  i — *  (upd  p  m  <p',  n);The 

\P;  A;  0,  pi-^  (ip,  n);  T  h  set  v  :=  v'\  e 

$;  A;0;rh  »  :  3r'  €p.cr  A  h  p;  :  R  k  VF;  A;  0;  F  h  v  :  3t' :  k.o 

A,  r :  R  k;  0,  ri— >p;  r,  a; :  cr[r'/r/]  he  \F;  A,  f  :k;  0;  F,  x:cr[t/f']  h  e 

A;  0;  T  h  let  (r,  *}  =  openrgn  v  in  e  $;A;0;Th  let  (t,  *}  =  open  v  in  e 

Ahp  :  Rk  <F;  A;  0,  pi-^  (p,  0);  F  h  e2 
\F;  A,  t 0,  pi— >  {p,  n);  F,  a:  :f  at  p.O  h  ei 
<F;  A;  0,  pi-^  {p,  n);  F  h  iffirst  p{x,t  .  e i)  (e2) 

>F;  A;  0;  T  h  y  <r  i  =  size  <r 
\F;  A;  0;  T  h  y  :  r  at  p.m  >F;  A;  0,  pi-^  (<p,  m+1);  rhe2 
A  h  p  :  R  k  \P;  A,  t :  k;  0,  pi— >  (<p,  n);  T,  x:t  at  p.m+1  h  ei 
\1/ ;  A;  0,  pt— >  (<p,  n);  F  h  ifnext  v  +  i  {x,  t  .  e\ )  (e2) 

Fig.  9.  Static  semantics  of  the  language. 


-  //tF;  A;  0;  r{a;:  er}  he  then  *F;  A;  0;  T  h  e[y/a;]. 

If  A  h  ip  :  k  then: 

-  If\ F;  A{f :  k};  0;  T  h  v  :  cr  then  *F;  A[<p/i];  0[<p/t];  T[ip/t\  h  v[ip/t]  :  a[p/t). 

-  7/tF;  A{f :  k};  0;  r  h  e  then  *F;  A [<p/f];  0[<p/i];  T[ip/t\  h  e[ip/t). 

Lemma  4  (Type  Preservation). 

If  h  (M;  0;  e)  and  (M;  0;  e)  =A-  (M';  0';  >F';  e')  //ten  h  (M';  0';  e'). 
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(tp;  A;0;r  b  v  :  a] 


\P;  A;  0;  T  h  Hi  :  ay 

*P;  A;  0;  T  b  x  :  r(*)  '5;  A;  0;  T  b  (hi,  V2)  :  u\  x  02 


<P;  A;  0;  F  b  n  :  int 

i/.n  £  Dom('l')  r  =  $(v.n)  tp;  A;  0;  x :  &  b  e 

<P;  A;  0;  T  b  v.n  :  r  at  v.n  *P;  A';  0';  T  b  A[A]{0}(a; : d).e  :  V[A]{0}(<?)  — +  0 

\P;  A;  0;  T  b  u  :  a[p/r\ 

A  b  ip  :  K  \t;A;0;rbw:a[i/)/(]  Abp:R«  A  b  ft  :  R  K  0  b  pep 
VP;  A;  0;  T  b  (<p,  v)  :  3 t:K.a  <P;  A;  0;  F  b  ( p ,  v)  :  3r£p.o 


(0  b  pep  VP;  A;0;F  b  v  >->■  a  \P;  A;  0;  F  b  op  :  a) 


p  £  p  0  b  Pi  €  p' 

0  b  p£p  0,pH^pbpep' 


0(p)  =  (<p,m) 

0  b  r  at  p.n  1 — >  p>  n  t 


0  b  t  at  pi.n  1  i  &[pi/p] 
0,  pt—> p  b  t  at  p.n  1 — ►  a 


>P;  A;  0;  F  b  v  :  r  at  p.n  0  b  r  at  p.n  1— >  <7 
^P;  A;  0;  r  b  H  cr 


\P;  A;  0;  F  b  v  1— >  a 
f;  A;0;P  b  get  v  :  a 


*P;  A;  0;  F  b  t>  :  <7i  X  <72  \P;  A;  0;  Y  b  v  :  o'  A  b  P  :  a'  <1  <7 

>P;  A;0;r  b  mv  :  <7,  <P;  A;0;T  b  cast [P]  v  :  a 


(0blivep  A  b  <7  :  t  rk  0b0'  o-<<7/] 


_  0  blive  pi 

0,  pi-^  (<p,  n)  bllve  p  0,  pi— >p  bllve  p 

_  _ 0  b  0' _ 

0b  0  0,pi-^(<p,n)  b  0',  pi-^  (<p,  n) 

<7l  <1  (7i  (72  <  <72 

a  <  (7  <7l  X  <72  <1  <7j  X  <72 


A  b  <7  :  K  A  b  <7  :  t:K,[a/t] 

A  b  cr,  <7  :  t :  K,  t :  K 

0  b  0'  0  b  p  €  p'  0  b  0' 

0  b  0',pi->p'  0,  pi— <■  p'  b  0' 

pCp'  (7  <  <7' 

3r  ep.<7  <  3re  p'.cr' 


Fig.  10.  Typing  values  and  operations,  with  auxiliary  titles. 


Lemma  5  (Progress). 

If  b  (M;  0;  *P;  e)  then  either  e  =  halt  v  or  there  exists  a  state  (M7 ;  0';  *P7;  e7)  such 
that  (M;  0;  >P;  e)  =>  (M7;  0';  'P';  e'). 

Lemma  6  (Complete  Collection). 

If  b  (M;  0;  <P;  e)  ant/  (M;  0;  >P;  e)  =b*  (M7;  07;  «P7;  e7) 

andVv.n  £  Dom(M) .  v  £  Dom(O)  then  \/v.n  £  Dom(M')  .  v  £  Dom(O'). 

In  particular,  if  e!  =  haltv  then  M’  =  •. 
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